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IPv6 Traffic Engineering in IS-IS 


Abstract 
This document specifies a method for exchanging IPv6 traffic 
engineering information using the IS-IS routing protocol. This 
information enables routers in an IS-IS network to calculate traffic- 
engineered routes using IPv6é addresses. 
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This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 


1. Overview 


The IS-IS routing protocol is defined in [IS-IS]. Each router 
generates a Link State PDU (LSP) that contains information describing 
the router and the links from the router. The information in the LSP 
is encoded in a variable length data structure consisting of a Type, 
Length, and Value. Such a data structure is referred to as a TLV. 


[TE] and [GMPLS] define a number of TLVs and sub-TLVs that allow 
Traffic Engineering (TE) information to be disseminated by the IS-IS 
protocol [IS-IS]. The addressing information passed in these TLVs is 
IPv4 specific. 


[IPv6] describes how the IS-IS protocol can be used to carry out 
Shortest Path First (SPF) routing for IPv6. It does this by defining 
IPv6-specific TLVs that are analogous to the TLVs used by IS-IS for 
carrying IPv4 addressing information. 


Multiprotocol Label Switching (MPLS) traffic engineering is very 
successful, and, as the use of IPv6 grows, there is a need to be able 
to support traffic engineering in IPv6 networks. 


This document defines the TLVs that allow traffic engineering 
information (including Generalized-MPLS (GMPLS) TE information) to be 
carried in IPv6é IS-IS networks. 


2. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [KEYWORDS]. 
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3. Summary of Operation 
3.1. Identifying IS-IS Links Using IPv6 Addresses 


Each IS-IS link has certain properties -- bandwidth, shared risk link 
groups (SRLGs), switching capabilities, and so on. The IS-IS 
extensions defined in [TE] and [GMPLS] describe how to associate 
these traffic engineering parameters with IS-IS links. These TLVs 
use IPv4 addresses to identify the link (or local/remote link 
identifiers on unnumbered links). 


When IPv6 is used, a numbered link may be identified by IPv4 and/or 
IPv6 interface addresses. The type of identifier used does not 
affect the properties of the link; it still has the same bandwidth, 
SRLGs, and switching capabilities. 


This document describes an approach for supporting IPv6 traffic 
engineering by defining TLV extensions that allow TE links and nodes 
to be identified by IPv6é addresses. 

3.1.1. IPv6é Address Types 
An IPv6 address can have global, unique-local, or link-local scope. 


- A global IPv6 address is valid within the scope of the Internet. 


- A unique-local IPv6 address is globally unique but is intended for 
local communication. 


- A link-local IPv6 address is valid only within the scope of a 
single link and may only be referenced on that link. 


Because the IPv6 traffic engineering TLVs present in LSPs are 
propagated across networks, they MUST NOT use link-local addresses. 


IS-IS does not need to differentiate between global and unique-local 
addresses. 


3.2. IP Addresses Used in Traffic Engineering TLVs 


This section lists the IP addresses used in the TLVs defined in [TE] 
and [GMPLS] and gives an overview of the required IPv6 equivalents. 
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3.2.1. TE Router ID TLV 


The TE Router ID TLV contains a stable IPv4 address that is routable, 
regardless of the state of each interface. 


Similarly, for IPv6, it is useful to have a stable IPv6 address 
identifying a TE node. The IPv6 TE Router ID TLV is defined in 
Section 4.1. 


EA IPv4 Interface Address Sub-TLV 


This sub-TLV of the Extended IS Reachability TLV contains an IPv4 
address for the local end of a link. The equivalent IPv6 Interface 
Address sub-TLV is defined in Section 4.2. 


3.2.3. IPv4 Neighbor Address Sub-TLV 


This sub-TLV of the Extended IS Reachability TLV is used for point- 
to-point links and contains an IPv4 address for the neighbor's end of 
a link. The equivalent IPv6 Neighbor Address sub-TLV is defined in 
Section 4.3. 


A router constructs the IPv4 Neighbor Address sub-TLV using one of 
the IPv4 addresses received in the IS-IS Hello (IIH) PDU from the 
neighbor on the link. 


The IPv6 Neighbor Address sub-TLV contains a globally unique IPv6 
address for the interface from the peer (which can be either a global 
or unique-local IPv6 address). The IPv6 Interface Address TLV 
defined in [IPv6] only contains link-local addresses when used in the 
IIH PDU. Hence, a neighbor's IP address from the IPv6 Interface 
Address TLV cannot be used when constructing the IPv6 Neighbor 
Address sub-TLV. Instead, we define an additional TLV, the IPv6 
Global Interface Address TLV in Section 4.5. The IPv6 Global 
Interface Address TLV is included in IIH PDUs to provide the globally 
unique IPv6 address that a neighbor router needs in order to 
construct the IPv6 Neighbor Address sub-TLV. 


3.2.4. IPv4 SRLG TLV 


The SRLG TLV (type 138) defined in [GMPLS] contains the set of SRLGs 
associated with a link. The SRLG TLV identifies the link using 
either local/remote IPv4 addresses or, for point-to-point unnumbered 
links, link-local/remote identifiers. The SRLG TLV includes a flags 
field to indicate which type of identifier is used. 
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When only IPv6 is used, IPv4 addresses and link-local/remote 
identifiers are not available to identify the link, but IPv6 
addresses can be used instead. 


There is no backward-compatible way to modify the SRLG TLV (type 138) 
to identify the link by IPv6 addresses; therefore, we need a new TLV. 


The IPv6 SRLG TLV is defined in Section 4.4. 
4. IPv6 TE TLVs 
4.1. IPv6 TE Router ID TLV 

The IPv6 TE Router ID TLV is TLV type 140. 


The IPv6 TE Router ID TLV contains a 16-octet IPv6 address. A stable 
global IPv6 address MUST be used, so that the router ID provides a 
routable address, regardless of the state of a node’s interfaces. 


If a router does not implement traffic engineering, it MAY include or 
omit the IPv6 TE Router ID TLV. If a router implements traffic 
engineering for IPv6, it MUST include this TLV in its LSP. This TLV 
MUST NOT be included more than once in an LSP. 


An implementation receiving an IPv6 TE Router ID TLV MUST NOT 
consider the router ID as a /128 reachable prefix in the standard SPF 
calculation because this can lead to forwarding loops when 
interacting with systems that do not support this TLV. 


Ae Des IPv6 Interface Address Sub-TLV 


The IPv6 Interface Address sub-TLV of the Extended IS Reachability 
TLV has sub-TLV type 12. It contains a 16-octet IPv6 address for the 
interface described by the containing Extended IS Reachability TLV. 
This sub-TLV can occur multiple times. 


Implementations MUST NOT inject a /128 prefix for the interface 
address into their routing or forwarding table because this can lead 
to forwarding loops when interacting with systems that do not support 
this sub-TLV. 


If a router implements the basic TLV extensions described in [TE], it 
MAY include or omit this sub-TLV. If a router implements IPv6 
traffic engineering, it MUST include this sub-TLV (except on an 
unnumbered point-to-point link, in which case the Link-Local 
Interface Identifiers sub-TLV is used instead). 


This sub-TLV MUST NOT contain an IPv6 link-local address. 


Harrison, et al. Standards Track [Page 5] 


RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011 


4.3. IPv6 Neighbor Address sub-TLV 


The IPv6 Neighbor Address sub-TLV of the Extended IS Reachability TLV 
has sub-TLV type 13. It contains a 16-octet IPv6 address for a 
neighboring router on the link described by the (main) TLV. This 
sub-TLV can occur multiple times. 


Implementations MUST NOT inject a /128 prefix for the interface 
address into their routing or forwarding table because this can lead 
to forwarding loops when interacting with systems that do not support 
this sub-TLVv. 


If a router implements the basic TLV extensions described in [TE], it 
MAY include or omit this sub-TLV. If a router implements IPv6 
traffic engineering, it MUST include this sub-TLV for point-to-point 
links (except on an unnumbered point-to-point link, in which case the 
Link-Local Interface Identifiers sub-TLV is used instead). 


This sub-TLV MUST NOT contain an IPv6 link-local address. 

4.4. IPv6 SRLG TLV 
The IPv6 SRLG TLV has type 139. The TLV carries the Shared Risk Link 
Group information (see the "Shared Risk Link Group Information" 


section of [GMPLS-—ROUTING]). 


It contains a data structure consisting of the following: 


6 octets of System ID 

1 octet of pseudonode number 

- 1 octet flags 

- 16 octets of IPv6 interface address 

(optional) 16 octets of IPv6 neighbor address 

(variable) list of SRLG values, where each element in the list has 
4 octets 


The following illustrates the encoding of the Value field of the IPv6 
SRLG TLV. 
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0 d 2 3 
On, 2-34 946. 7 58.9 042 3 4 S E 28 G0 2 3 Ao T E A OO 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| System ID | 
FPP rt tata tartar tartan tata tanta ttt tata tata tatatatatatatatatat 
| System ID (cont.) | Pseudonode num Flags | 


tata tata tata tata tata tata ta ta tata tata ta ta tata tata ta tata tata tatatat 
| IPv6 interface address 

tata t ata tata tata tata ta tata ta tata ta tata tata ta tata ta tata tata tata tat 
| IPv6 interface address (continued) 

tata ta tate tata tata ta ta tata tata ta tata ta tata ta tata ta tata tata tata tat 
| IPv6é interface address (continued) 

tata ta tata tata ta tata ta tata ta tata tata ta ta tata tata ta tata HH 
| IPv6é interface address (continued) 

tata tatatartata tae tata ta tata ta tata tata ta tata ta ta tata ta tata ta tatatat 
| (optional) IPv6 neighbor address 

tata t ata taeda tata tata ta tata tata ta ta tata tata HH 
| IPv6 neighbor address (continued) 

tata tata ta tata tartar ta tartar ta ta tata tata ta tata ta tata tata tata ta tatatat 
| IPv6 neighbor address (continued) 

tata ta ta tata tate ta tata tata ta tata tata ta tata ta tata ta ta tata tata tatat 
| IPv6 neighbor address (continued) 

tata tatatatata ta tata ta tata tata ta ta tata tata ta tata ta tata tata tata tat 
| Shared Risk Link Group Value 

tata t ata ta tata ta tata ta tata tata ta tata ta ta tata tata ta ta tata ta tata tat 
Da a E DEE E a ee 
| Shared Risk Link Group Value 

tata tata tata ta ta tata tata ta ta tata tata ta tat ata tata ta tata ta tata ta tat 


The neighbor is identified by its System ID (6 octets), plus one 
octet to indicate the pseudonode number if the neighbor is on a LAN 
interface. 
The l-octet flags field is interpreted as follows. 
Flags (1 octet) 

OF 22° 3. Ap 5). 6 7 

+—--+--+--+--+--+--+--+--+ 

| Reserved | NA | 

+—--+--+--+--+--+--+--+--+ 

NA - Neighbor Address included. 
The flags field currently contains one flag to indicate whether the 


IPv6 neighbor address is included (the NA bit is set to 1) or not 
included (the NA bit is set to 0). 
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Other bits in the flags field are reserved for future use. Any bits 
not understood by an implementation MUST be set to zero by the 
sender. If a router receives an IPv6 SRLG TLV with non-zero values 
for any bit that it does not understand, it MUST ignore the TLV (in 
other words, it does not use the TLV locally but floods the TLV 
unchanged to neighbors as normal). 


Note that this rule for processing the flags octet allows for future 
extensibility of the IPv6é SRLG TLV. In particular, it allows 
alternative means of identifying the corresponding link to be added 
in the future. An implementation that does not understand such an 
extension will ignore the TLV rather than attempt to interpret the 
TLV incorrectly. 


The length of this TLV is 24 + 4 * (number of SRLG values) + 16 (if 
the IPv6 neighbor address is included). 


To prevent an SRLG TLV and an IPv6 SRLG TLV in the same logical LSP 
from causing confusion of interpretation, the following rules are 
applied. 


- The IPv6 SRLG TLV MAY occur more than once within the IS-IS 
logical LSP. 


-— There MUST NOT be more than one IPv6 SRLG TLV for a given link. 


- The IPv6 SRLG TLV (type 139) MUST NOT be used to describe the 
SRLGs for a given link if it is possible to use the SRLG TLV (type 
138). 


- If both an SRLG TLV and an IPv6 SRLG are received describing the 
SRLGs for the same link, the receiver MUST apply the SRLG TLV and 
ignore the IPv6 SRLG TLV. 


In other words, if SRLGs are to be advertised for a link and if the 
Extended IS Reachability TLV describing a link contains IPv4 
interface/neighbor address sub-TLVs or the link-local identifiers 
sub-TLV, then the SRLGs MUST be advertised in the SRLG TLV (type 
138). 


4.5. IPv6 Global Interface Address TLV 


The IPv6 Global Interface Address TLV is TLV type 233. The TLV 
structure is identical to that of the IPv6 Interface Address TLV 


defined in [IPv6], but the semantics are different. In particular, 
the TLV is included in IIH PDUs for those interfaces using IPv6 TE 
extensions. The TLV contains global or unique-local IPv6 addresses 


assigned to the interface that is sending the Hello. 


Harrison, et al. Standards Track [Page 8] 


RFC 6119 IPv6 Traffic Engineering in IS-IS February 2011 


The IPv6 Global Interface Address TLV is not used in LSPs. 
5. Security Considerations 


This document raises no new security issues for IS-IS; for general 
security considerations for IS-IS, see [ISIS-AUTH]. 


6. IPv4/IPv6 Migration 


The IS-IS extensions described in this document allow the routing of 
GMPLS Label Switched Paths using IPv6é addressing through an IS-IS 
network. There are no migration issues introduced by the addition of 
this IPv6 TE routing information into an existing IPv4 GMPLS network. 
Migration of Label Switched Paths from IPv4 to IPv6 is an issue for 
GMPLS signaling and is outside the scope of this document. 


7. IANA Considerations 


This document defines the following new IS-IS TLV types that IANA has 
reflected in the IS-IS TLV code-point registry: 


Type Description IIH LSP SNP 
139 IPv6 SRLG TLV n y n 
140 IPv6 TE Router ID n y n 
233 IPv6 Global Interface y n n 


Address TLV 


This document also defines the following new sub-TLV types of top- 
level TLV 22 that IANA has reflected in the Sub-TLVs for TLV 22, 141, 
and 222 registry: 


Type Description 22 141 222 Length 
12 IPv6 Interface Address y y y 16 
13. IPv6 Neighbor Address y y y 16 
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